CD Actual 2/CD ACTUAL VOL 2.iso/docs/kernel-h

Text File | 1995-09-10 | 41.8 KB | 1,234 lines

  The Linux Kernel HOWTO
  Brian Ward, [e-mail]
  v0.31, 31 March 1995

  This is a detailed guide to kernel configuration, compilation, and
  upgrades.

  1.  Introduction


  This is release 0.31 of the Kernel-HOWTO. Should you read this
  document?  Well, see if you've got any of the following symptoms:



  o  ``Arg! This wizzo-46.5.6 package says it needs kernel release
     1.1.193 and I still only have release 1.0.9!''

  o  There's a device driver in one of the newer kernels that you just
     gotta have

  o  You really have no idea at all how to compile a kernel

  o  ``Is this stuff in the README really the whole story?''

  o  You came, you tried, it didn't work

  o  You know how to compile and install a kernel, and people seem to
     know this. Therefore, they keep whining to you to help them install
     their kernels.


  1.1.  Read this first! (I mean it)

  Some of the examples in this document assume that you have GNU tar,
  find, and xargs. These are quite standard; this should not cause
  problems. It is also assumed that you know your system's filesystem
  structure; if you don't, it is critical that you keep a written copy
  of the mount command's output during normal system operation (or a
  listing of /etc/fstab, if you can read it). This information is
  important, and does not change unless you repartition your disk, add a
  new one, reinstall your system, or something similar.


  The latest kernel version at the time of this writing was 1.2.2,
  meaning that the references and examples correspond to that release.
  Even though I try to make this document as version-independent as
  possible, the kernel is constantly under development, so if you get a
  newer release, it will inevitably have some differences. Again, this
  should not cause major problems, but it may create some confusion.



  1.2.  A word on style

  Text that looks like this is either something that appears on your
  screen, a filename, or something that can be directly typed in, such
  as a command, or options to a command (if you're looking at a plain-
  text file, it doesn't look any different). Commands and other input
  are frequently quoted (with ` '), which causes the following classic
  punctuation problem: if such an item appears at the end of a sentence
  in quotes, people often type a `.' along with the command, because the
  American quoting style says to put the period inside of the quotation
  marks. Even though common sense should tell one to strip off the
  punctuation first, many people simply do not remember, so I will place
  it outside the quotation marks in such cases. For example, I would
  write `make config', not `make config.'


  2.  Important questions and their answers



  2.1.  What does the kernel do, anyway?


  The Unix kernel acts as a mediator for your programs. First, it does
  the memory management for all of the running programs (processes), and
  makes sure that they all get a fair (or unfair, if you please) share
  of the processor's cycles. In addition, it provides a nice, fairly
  portable interface for programs to talk to your hardware.


  Obviously, there is more to the kernel's operation than this, but the
  basic functions above are the most important to know.



  2.2.  Why would I want to upgrade my kernel?


  Newer kernels generally offer the ability to talk to more types of
  hardware (that is, they have more device drivers), they can have
  better process management, they can run faster than the older
  versions, they could be more stable than the older versions, and they
  fix silly bugs in the older versions. Most people upgrade kernels
  because they want the device drivers and the bug fixes.



  2.3.  What kind of hardware do the newer kernels support?


  See the Hardware-HOWTO. Alternatively, you can look at the `config.in'
  file in the linux source, or just find out when you try `make config'.
  This shows you all hardware supported by the standard kernel
  distribution, but not everything that linux supports; many common
  device drivers (such as the PCMCIA drivers and some tape drivers) are
  loadable modules maintained and distributed separately.



  2.4.  What version of gcc and libc do I need?


  Linus recommends a version of gcc in the README file included with the
  linux source. If you don't have this version, the documentation in the
  recommended version of gcc should tell you if you need to upgrade your
  libc.  This is not a difficult procedure, but it is important to
  follow the instructions.



  2.5.  What's a loadable module?


  These are pieces of kernel code which are not linked (included)
  directly in the kernel. One compiles them separately, and can insert
  and remove them into the running kernel at almost any time. Due to its
  flexibility, this is now the preferred way to code certain kernel
  features. Many popular device drivers, such as the PCMCIA drivers and
  the QIC-80/40 tape driver, are loadable modules.
  2.6.  How much disk space do I need?


  It depends on your particular system configuration. First, the
  compressed linux source is 2.35 megabytes large at version 1.2.0. Most
  keep this even after unpacking.  Uncompressed, it takes up 10 MB. But
  that's not the end -- you need more to actually compile the thing.
  This depends on how much you configure into your kernel. For example,
  on my 386, I have networking, the 3Com 3C503 driver, and five
  filesystems configured, using 18 MB. Adding the compressed linux
  source, you need about 20 MB for this particular configuration. On
  another system, without network device support (but still with
  networking support), and sound card support, it consumes 14 MB. Also,
  a newer kernel is certain to have a larger source tree than an older
  one, so, in general, if you have a lot of hardware, make sure that you
  have a big enough hard disk in that mess.



  2.7.  How long does it take?


  For most people, the answer is ``fairly long.'' The speed of your
  system and the amount of memory you have ultimately determines the
  time, but there is a small bit to do with the amount of stuff you
  configure into the kernel. On a 486DX4/100 notebook with 16 MB of RAM,
  on a kernel with five filesystems, networking support, and sound card
  drivers, it takes under 20 minutes. On a 386DX/40 (8 MB RAM) with a
  similar configuration, compilation lasts nearly 1.5 hours. It is a
  generally good recommendation to make a little coffee, watch some TV,
  knit, or whatever you do for fun while your machine compiles the
  kernel.



  3.  How to actually configure the kernel



  3.1.  Getting the source


  You can obtain the source via anonymous ftp from ftp.funet.fi in
  /pub/OS/Linux/PEOPLE/Linus, a mirror, or other sites.  It is typically
  labelled linux-x.y.z.tar.gz, where x.y.z is the version number. Newer
  (better?) versions and the patches are typically in subdirectories
  such as `v1.1' and `v1.2' The highest number is the latest version,
  and is usually a ``test release,'' meaning that if you feel uneasy
  about beta or alpha releases, you should stay with a major release.


  I strongly suggest that you use a mirror ftp site instead of
  ftp.funet.fi. Here is a short list of mirrors and other sites:


  USA:            tsx-11.mit.edu:/pub/linux/sources/system
  USA:            sunsite.unc.edu:/pub/Linux/kernel
  UK:             unix.hensa.ac.uk:/pub/linux/kernel
  Austria:        fvkma.tu-graz.ac.at:/pub/linux/linus
  Germany:        ftp.Germany.EU.net:/pub/os/Linux/Local.EUnet/Kernel/Linus
  Germany:        ftp.dfv.rwth-aachen.de:/pub/linux/kernel
  France:         ftp.ibp.fr:/pub/linux/sources/system/patches
  Australia:      kirk.bond.edu.au:/pub/OS/Linux/kernel



  If you do not have ftp access, a list of BBS systems which carry linux
  is posted periodically to comp.os.linux.announce; try to obtain this.



  3.2.  Unpacking the source


  Log in as or su to `root', and cd to /usr/src.  If you installed
  kernel source when you first installed linux (as most do), there will
  already be a directory called `linux' there, which contains the entire
  old source tree.  If you have the disk space and you want to play it
  safe, preserve that directory. A good idea is to figure out what
  version your system runs now and rename the directory accordingly. The
  command `uname -r' prints the current kernel version.  Therefore, if
  `uname -r' said `1.1.47', you would rename (with `mv') `linux' to
  `linux-1.1.47'.  If you feel mildly reckless, just wipe out the entire
  directory. In any case, make certain there is no `linux' directory in
  /usr/src before unpacking the full source code.


  Now, in /usr/src, unpack the source with `tar zxvf linux-x.y.z.tar.gz'
  (if you've just got a .tar  file with no .gz at the end, `tar xvf
  linux-x.y.z.tar' works.).  The contents of the source will fly by.
  When finished, there will be a new `linux' directory in /usr/src. cd
  to linux and look over the README  file.  There will be a section with
  the label `INSTALLING the kernel'.  Carry out the instructions when
  appropriate -- symbolic links that should be in place, removal of
  stale .o files, etc.



  3.3.  Configuring the kernel


  Note: Some of this is reiteration/clarification of a similar section
  in Linus' README file.


  The command `make config' while in /usr/src/linux starts a configure
  script which asks you many questions. It requires bash, so verify that
  bash is /bin/bash, /bin/sh, or $BASH.


  You are ready to answer the questions, usually with `y' (yes) or `n'
  (no). Some of the more obvious and non-critical options are not
  described here; see the section ``Other configuration options'' for
  short descriptions of a few others.



  3.3.1.  Kernel math emulation


  If you don't have a math coprocessor (you have a bare 386 or 486SX),
  you must say `y' to this. If you do have a coprocessor and you still
  say `y', don't worry too much -- the coprocessor is still used and the
  emulation ignored. The only consequence is that the kernel will be
  larger (costing RAM).



  3.3.2.  Normal (MFM/RLL) disk and IDE disk/cdrom support



  You probably need to support this; it means that the kernel will
  support standard PC hard disks, which most people have. This driver
  does not include SCSI drives; they come later in the configuration.

  You will then be asked about the ``old disk-only'' and ``new IDE''
  drivers.  You want to choose one of them; the main difference is that
  the old driver only supports two disks on a single interface, and the
  new one supports a secondary interface and IDE/ATAPI cdrom drives. The
  new driver is 4k larger than the old one and is also supposedly
  ``improved,'' meaning that aside from containing a different number of
  bugs, it might improve your disk performance, especially if you have
  newer hardware.



  3.3.3.  Networking support


  In principle, you would only say `y' if your machine is on a network
  such as the internet, or you want to use SLIP, PPP, term, etc to dial
  up for internet access. However, as many packages (such as X windows)
  require networking support even if your machine does not live on a
  real network, you should say `y'. Later on, you will be asked if you
  want to support TCP/IP networking; again, say `y' here if you are not
  absolutely sure.



  3.3.4.  Limit memory to low 16MB


  There exist buggy 386 DMA controllers which have problems with
  addressing anything more than 16 MB of RAM; you want to say `y' in the
  (rare) case that you have one.



  3.3.5.  System V IPC


  One of the best definitions of IPC (Interprocess Communication) is in
  the Perl book's glossary. Not surprisingly, Perl employs it to let
  processes talk to each other, as well as many other packages, so it is
  not a good idea to say n unless you know exactly what you are doing.



  3.3.6.  Use -m486 flag for 486-specific optimizations


  This optimizes the kernel for use on a 486 processor. The new kernel
  will be slightly larger, but will work fine on a 386.



  3.3.7.  SCSI support


  If you have a SCSI device, say `y'. You will be prompted for further
  information, such as support for CD-ROM, disks, and what kind of SCSI
  adapter you have. See the SCSI-HOWTO for greater detail.





  3.3.8.  Network device support


  If you have a network card, or you would like to use SLIP, PPP, or a
  parallel port adapter, say `y'. The config script will prompt for
  which kind of card you have, and which protocol to use.



  3.3.9.  Filesystems


  The configure script then asks if you wish to support the following
  filesystems:


  Standard (minix) - Newer distributions don't create minix filesystems,
  and many people don't use it, but it may still be a good idea to
  configure this one. Some ``rescue disk'' programs use it, and still
  more floppies may have a minix filesystem, since the minix filesystem
  is fairly optimal for floppy disks.


  Extended fs - This was the first version of the extended filesystem,
  which is no longer in widespread use. Chances are, you'll know it if
  you need it.


  Second extended - This is widely used in new distributions. You
  probably have one of these, and need to say `y'.


  xiafs filesystem - At one time, this was not uncommon, but at the time
  of this writing, I did not know of anyone using it.


  msdos - If you want to use your MS-DOS hard disk partitions, or mount
  MS-DOS formatted floppy disks, say `y'.


  umsdos - This filesystem expands an MS-DOS filesystem with usual Unix-
  like features such as long filenames. It is not useful for people
  (like me) who ``don't do DOS.''


  /proc - Another one of the greatest things since powdered milk (idea
  shamelessly stolen from Bell Labs, I guess). One doesn't make a proc
  filesystem on a disk; this is a filesystem interface to the kernel and
  processes. Many process listers (such as `ps') use it. Try `cat
  /proc/meminfo' or `cat /proc/devices' sometime.  Some shells (rc, in
  particular) use /proc/self/fd  (known as /dev/fd on other systems) for
  I/O. You should almost certainly say `y' to this; many important linux
  tools depend on it.


  NFS - If your machine lives on a network and you want to share files
  with other systems using NFS, say `y'.


  ISO9660 - Found on most CD-ROMs.


  OS/2 HPFS - At the time of this writing, a read-only fs for OS/2 HPFS.



  System V and Coherent - for partitions of System V and Coherent
  systems (These are other PC Unix variants).



  3.3.9.1.  But I don't know which filesystems I need!


  Ok, type `mount'. The output will look something like this:




               blah# mount
               /dev/hda1 on / type ext2 (defaults)
               /dev/hda3 on /usr type ext2 (defaults)
               none on /proc type proc (defaults)
               /dev/fd0 on /mnt type msdos (defaults)




  Look at each line; the word next to `type' is the filesystem type. In
  this example, my /  and /usr filesystems are second extended, I'm
  using /proc, and there's a floppy disk mounted using the msdos (bleah)
  filesystem.

  You can try `cat /proc/filesystems' if you have /proc currently
  enabled; it will list your current kernel's filesystems.

  The configuration of rarely-used, non-critical filesystems can cause
  kernel bloat; see the section on modules for a way to avoid this.



  3.3.10.  Character devices


  Here, you enable the drivers for your printer, busmouse, PS/2 mouse
  (many notebooks use the PS/2 mouse protocol for their built-in
  trackballs), some tape drives, and other such ``character'' devices.
  Say `y' when appropriate.


  Note: Selection is a program which allows the use of the mouse outside
  of X Windows for cut and paste between virtual consoles. It's fairly
  nice if you have a serial mouse, because it coexists well with X
  Windows, but you need to do special tricks for others. Selection
  support was a configuration option at one time, but is now standard.



  3.3.11.  Sound card


  If you feel a great desire to hear biff bark, say `y', and later on,
  another config program will compile and ask you all about your sound
  board. (A note on sound card configuration: when it asks you if you
  want to install the full version of the driver, you can say `n' and
  save some kernel memory by picking only the features which you deem
  necessary.)





  3.3.12.  Kernel hacking


  >From Linus' README:

  the ``kernel hacking'' configuration details usually result in a
  bigger or slower kernel (or both), and can even make the kernel less
  stable by configuring some routines to actively try to break bad code
  to find kernel problems (kmalloc()).  Thus you should probably answer
  `n' to the questions for a ``production'' kernel.



  3.4.  Now what? (The Makefile)


  After you make config, a message tells you that your kernel has been
  configured, and to ``check the top-level Makefile for additional
  configuration,'' etc.


  So, look at the Makefile. You probably will not need to change it, but
  it never hurts to look. You can also change its options with the
  `rdev' command once the new kernel is in place.



  4.  Compiling the kernel



  4.1.  Cleaning and depending


  When the configure script ends, it also tells you to `make dep' and
  `clean'.  So, do the `make dep'. This insures that all of the
  dependencies, such the include files, are in place. It does not take
  long, unless your computer is fairly slow to begin with.  When
  finished, do a `make clean'.  This removes all of the object files and
  some other things that an old version leaves behind. Don't forget this
  step.



  4.2.  Compile time


  After depending and cleaning, you may now `make zImage' or `make
  zdisk' (This is the part that takes a long time.)  `make zImage' will
  compile the kernel, and leave a file in arch/i386/boot called `zImage'
  (among other things). This is the new compressed kernel. `make zdisk'
  does the same thing, but also places the new zImage on a floppy disk
  which you hopefully put in drive ``A:''.  `zdisk' is fairly handy for
  testing new kernels; if it bombs (or just doesn't work right), just
  remove the floppy and boot with your old kernel. It can also be a
  handy way to boot if you accidentally remove your kernel (or something
  equally as dreadful). You can also use it to install new systems when
  you just dump the contents of one disk onto the other (``all this and
  more! NOW how much would you pay?'').


  All reasonably recent kernels are compressed, hence the `z' in front
  of the names. A compressed kernel automatically decompresses itself
  when executed.


  4.3.  Other ``make''ables


  `make mrproper' will do a more extensive `clean'ing.  It is sometimes
  necessary; you may wish to do it at every patch. See the section on
  modules for a description of `make modules'.


  4.4.  Installing the kernel

  After you have a new kernel that seems to work the way you want it to,
  it's time to install it. Most people use LILO (Linux Loader) for this.
  `make zlilo' will install the kernel, run LILO on it, and get you all
  ready to boot, BUT ONLY if lilo is configured in the following way on
  your system: kernel is /vmlinuz, lilo is in /sbin, and your lilo
  config (/etc/lilo.conf) agrees with this.


  Otherwise, you need to use LILO directly. It's a fairly easy package
  to install and work with, but it has a tendency to confuse people with
  the configuration file.  Look at the config file (either
  /etc/lilo/config for older versions or /etc/lilo.conf for new
  versions), and see what the current setup is. The config file looks
  like this:



      image = /vmlinuz
          label = Linux
          root = /dev/hda1
          ...



  The `image =' is set to the currently installed kernel.  Most people
  use /vmlinuz. `label' is used by lilo to determine which kernel or
  operating system to boot, and `root' is the / of that particular
  operating system. Make a backup copy of your old kernel and copy the
  zImage which you just made into place (you would say `cp zImage
  /vmlinuz' if you use `/vmlinuz').  Then, rerun lilo -- on newer
  systems, you can just run `lilo', but on older stuff, you might have
  to do an /etc/lilo/install or even an /etc/lilo/lilo -C
  /etc/lilo/config.


  If you would like to know more about LILO's configuration, or you
  don't have LILO, get the newest version from your favorite ftp site
  and follow the instructions.


  To boot one of your old kernels off the hard disk (another way to save
  yourself in case you screw up the new kernel), copy the lines below
  (and including) `image = xxx' in the LILO config file to the bottom of
  the file, and change the `image = xxx' to `image = yyy', where `yyy'
  is the full pathname of the file you saved your backup kernel to.
  Then, change the `label = zzz' to `label = linux-backup' and rerun
  lilo. You may need to put a line in the config file saying `delay=x',
  where x is an amount in tenths of a second, which tells LILO to wait
  that much time before booting, so that you can interrupt it (with the
  shift key, for example), and type in the label of the backup boot
  image (in case unpleasant things happen).





  5.  Patching the kernel



  5.1.  Applying a patch


  Incremental upgrades of the kernel are distributed as patches. For
  example, if you have version 1.1.45, and you notice that there's a
  `patch46.gz' out there for it, it means you can upgrade to version
  1.1.46 through application of the patch. You might want to make a
  backup of the source tree first (`make clean' and then `cd /usr/src;
  tar zcvf old-tree.tar.gz linux' will make a compressed tar archive for
  you.).


  So, continuing with the example above, let's suppose that you have
  `patch46.gz' in /usr/src. cd to /usr/src  and do a `zcat patch46.gz |
  patch -p0' (or `patch -p0 < patch46' if the patch isn't compressed).
  You'll see things whizz by (or flutter by, if your system is that
  slow) telling you that it is trying to apply hunks, and whether it
  succeeds or not. Usually, this action goes by too quickly for you to
  read, and you're not too sure whether it worked or not, so you might
  want to use the -s flag to patch, which tells patch to only report
  error messages (you don't get as much of the ``hey, my computer is
  actually doing something for a change!'' feeling, but you may prefer
  this..). To look for parts which might not have gone smoothly, cd to
  /usr/src/linux  and look for files with a .rej extension. Some
  versions of patch (older versions which may have been compiled with on
  an inferior filesystem) leave the rejects with a # extension. You can
  use `find' to look for you;

  find .  -name '*.rej' -print


  prints all files who live in the current directory or any subdirecto-
  ries with a .rej extension to the standard output.


  If everything went right, do a `make clean', `config', and `dep' as
  described in sections 3 and 4.


  There are quite a few options to the patch command. As mentioned
  above, patch -s will suppress all messages except the errors. If you
  keep your kernel source in some other place than /usr/src/linux, patch
  -p1 (in that directory) will patch things cleanly. Other patch options
  are well-documented in the manual page.



  5.2.  If something goes wrong


  The most frequent problem that used to arise was when a patch modified
  a file called `config.in' and it didn't look quite right, because you
  changed the options to suit your machine. This has been taken care of,
  but one still might encounter it with an older release.  To fix it,
  look at the config.in.rej  file, and see what remains of the original
  patch.  The changes will typically be marked with `+' and `-' at the
  beginning of the line. Look at the lines surrounding it, and remember
  if they were set to `y' or `n'. Now, edit config.in, and change `y' to
  `n' and `n' to `y' when appropriate. Do a

  patch -p0 < config.in.rej

  and if it reports that it succeeded (no fails), then you can continue
  on with a configuration and compilation. The config.in.rej file will
  remain, but you can get delete it.


  If you encounter further problems, you might have installed a patch
  out of order. If patch says `previously applied patch detected: Assume
  -R?', you are probably trying to apply a patch which is below your
  current version number; if you answer `y', it will attempt to degrade
  your source, and will most likely fail; thus, you will need to get a
  whole new source tree (which might not have been such a bad idea in
  the first place).


  To back out (unapply) a patch, use `patch -R' on the original patch.


  The best thing to do when patches really turn out wrong is to start
  over again with a clean, out-of-the-box source tree (for example, from
  one of the linux-x.y.z.tar.gz  files), and start again.



  5.3.  Getting rid of the .orig files


  After just a few patches, the .orig  files will start to pile up. For
  example, one 1.1.51 tree I had was once last cleaned out at 1.1.48.
  Removing the .orig files saved over a half a meg.

  find .  -name '*.orig' -exec rm -f {} ';'


  will take care of it for you. Versions of patch which use # for
  rejects use a tilde instead of .orig.

  There are better ways to get rid of the .orig files, which depend on
  GNU xargs:

  find .  -name '*.orig' | xargs rm


  or the ``quite secure but a little more verbose'' method:

  find . -name '*.orig' -print0 | xargs --null rm --





  5.4.  Other patches


  There are other patches (I'll call them ``nonstandard'') than the ones
  Linus distributes. If you apply these, Linus' patches may not work
  correctly and you'll have to either back them out, fix the source or
  the patch, install a new source tree, or a combination of the above.
  This can become very frustrating, so if you do not want to modify the
  source (with the possibility of a very bad outcome), back out the
  nonstandard patches before applying Linus', or just install a new
  tree. Then, you can see if the nonstandard patches still work. If they
  don't, you are either stuck with an old kernel, playing with the patch
  or source to get it to work, or waiting (possibly begging) for a new
  version of the patch to come out.


  How common are the patches not in the standard distribution? You will
  probably hear of them. I use the noblink patch for my virtual consoles
  because I hate blinking cursors (This patch is frequently updated for
  new kernel releases.).



  6.  Additional packages

  Your linux kernel has many features which are not explained in the
  kernel source itself; these features are typically utilized through
  external packages. Some of the most common are listed here.



  6.1.  kbd

  The linux console probably has more features than it deserves. Among
  these are the ability to switch fonts, remap your keyboard, switch
  video modes (in newer kernels), etc. The kbd package has programs
  which allow the user to do all of this, plus many fonts and keyboard
  maps for almost any keyboard, and is available from the same sites
  that carry the kernel source.



  6.2.  util-linux

  Rik Faith ([e-mail]) keeps a large collection of linux
  utilities which are, by odd coincidence, called util-linux. Available
  via anonymous ftp from sunsite.unc.edu in /pub/Linux/system/Misc, it
  contains programs such as setterm, rdev, and ctrlaltdel, which are
  relevant to the kernel. As Rik says, do not install without thinking;
  you do not need to install everything in the package, and it could
  very well cause serious problems if you do.



  6.3.  hdparm

  As with many packages, this was once a kernel patch and support
  programs.  The patches made it into the official kernel, and the
  programs to optimize and play with your hard disk are distributed
  separately.



  7.  Some pitfalls



  7.1.  make clean


  If your new kernel does really weird things after a routine kernel
  upgrade, chances are you forgot to make clean before compiling the new
  kernel. Symptoms can be anything from your system outright crashing,
  strange I/O problems, to crummy performance. Make sure you do a make
  dep, too.



  7.2.  Huge or slow kernels



  If your kernel is sucking up a lot of memory, is too large, or just
  takes forever to compile even when you've got your new 486DX6/440
  working on it, you've probably got lots of unneeded stuff (device
  drivers, filesystems, etc) configured. If you don't use it, don't
  configure it, because it does take up memory.  The most obvious
  symptom of kernel bloat is extreme swapping in and out of memory to
  disk; if your disk is making a lot of noise, look over your kernel
  configuration.


  You can find out how much memory the kernel is using by taking the
  total amount of memory in your machine and subtracting it from the
  amount of ``total mem'' in /proc/meminfo  or the output of the command
  `free'. You can also find out by doing a `dmesg' (or by looking at the
  kernel log file, wherever it is on your system).  There will be a line
  which looks like this:


  Memory: 15124k/16384k available (552k kernel code, 384k reserved, 324k
  data)


  My 386 (which has slightly less junk configured) says this:


  Memory: 7000k/8192k available (496k kernel code, 384k reserved, 312k
  data)



  7.3.  Kernel doesn't compile


  If it does not compile, then it is likely that a patch failed, or your
  source is somehow corrupt. Your version of gcc also might not be
  correct, or could also be corrupt (for example, the include files
  might be in error). Make sure that the symbolic links which Linus
  describes in the README are set up correctly. In general, if a
  standard kernel does not compile, something is seriously wrong with
  the system, and reinstallation of certain tools is probably necessary.



  7.4.  New version of the kernel doesn't seem to boot


  You did not run LILO, or it is not configured correctly. One thing
  that ``got'' me once was a problem in the config file; it said `boot =
  /dev/hda1' instead of `boot = /dev/hda' (This can be really annoying
  at first, but once you have a working config file, you shouldn't need
  to change it.).



  7.5.  You forgot to run LILO, or system doesn't boot at all


  Ooops! The best thing you can do here is to boot off of a floppy disk
  and prepare another bootable floppy (such as `make zdisk' would do).
  You need to know where your root (/) filesystem is and what type it is
  (e.g. second extended, minix). In the example below, you also need to
  know what filesystem your /usr/src/linux source tree is on, its type,
  and where it is normally mounted.



  In the following example, / is /dev/hda1, and the filesystem which
  holds /usr/src/linux is /dev/hda3, normally mounted at /usr. Both are
  second extended filesystems. The working kernel image in
  /usr/src/linux/arch/i386/boot is called zImage.


  The idea is that if there is a functioning zImage, it is possible to
  use that for the new floppy. Another alternative, which may or may not
  work better (it depends on the particular method in which you messed
  up your system) is discussed after the example.


  First, boot from a boot/root disk combo or rescue disk, and mount the
  filesystem which contains the working kernel image:



  mkdir /mnt
  mount -t ext2 /dev/hda3 /mnt



  If mkdir tells you that the directory already exists, just ignore it.
  Now, cd to the place where the working kernel image was. Note that

  /mnt + /usr/src/linux/arch/i386/boot - /usr = /mnt/src/linux/arch/i386/boot


  Place a formatted disk in drive ``A:'' (not your boot or root disk!),
  dump the image to the disk, and configure it for your root filesystem:



  cd /mnt/src/linux/arch/i386/boot
  dd if=zImage of=/dev/fd0
  rdev /dev/fd0 /dev/hda1



  cd to / and unmount the normal /usr filesystem:


  cd /
  umount /mnt



  You should now be able to reboot your system as normal from this
  floppy.  Don't forget to run lilo (or whatever it was that you did
  wrong) after the reboot!


  As mentioned above, there is another common alternative. If you
  happened to have a working kernel image in / (/vmlinuz for example),
  you can use that for a boot disk. Supposing all of the above
  conditions, and that my kernel image is /vmlinuz, just make these
  alterations to the example above: change /dev/hda3 to /dev/hda1 (the /
  filesystem), /mnt/src/linux to /mnt, and if=zImage to if=vmlinuz. The
  note explaining how to derive /mnt/src/linux may be ignored.



  7.6.  It says `warning: bdflush not running'



  This can be a severe problem. Starting with a kernel release after 1.0
  (around 20 Apr 1994), a program called `update' which periodically
  flushes out the filesystem buffers, was upgraded/replaced. Get the
  sources to `bdflush' (you should find it where you got your kernel
  source), and install it (you probably want to run your system under
  the old kernel while doing this). It installs itself as `update' and
  after a reboot, the new kernel should no longer complain.



  7.7.  It says weird things about obsolete routing requests


  Get new versions of the route program and any other programs which do
  route manipulation.  /usr/include/linux/route.h  (which is actually a
  file in /usr/src/linux) has changed.



  7.8.  Firewalling not working in 1.2.0

  Upgrade to at least version 1.2.1.



  8.  Modules

  Loadable kernel modules can save memory and ease configuration. The
  scope of modules has grown to include filesystems, ethernet card
  drivers, tape drivers, printer drivers, and more.



  8.1.  Installing the module utilities

  The module utilities are available from wherever you got your kernel
  source as modules-x.y.z.tar.gz; choose the highest patchlevel x.y.z
  that is equal to or below that of your current kernel. Unpack it with
  `tar zxvf modules-x.y.z.tar.gz', cd to the directory it creates
  (modules-x.y.z), look over the README, and carry out its installation
  instructions (which is usually something simple, such as make
  install). You should now have the programs insmod, rmmod, ksyms,
  lsmod, genksyms, modprobe, and depmod in /sbin. If you wish, test out
  the utilities with the ``hw'' example driver in insmod; look over the
  INSTALL file in that subdirectory for details.

  insmod inserts a module into the running kernel. Modules usually have
  a .o extension; the example driver mentioned above is called
  drv_hello.o, so to insert this, one would say `insmod drv_hello.o'. To
  see the modules that the kernel is currently using, use lsmod. The
  output looks like this:

  blah# lsmod
  Module:        #pages:  Used by:
  drv_hello          1


  `drv_hello' is the name of the module, it uses one page (4k) of mem-
  ory, and no other kernel modules depend on it at the moment. To remove
  this module, use `rmmod drv_hello'. Note that rmmod wants a module
  name, not a filename; you get this from lsmod's listing. The other
  module utilities' purposes are documented in their manual pages.




  8.2.  Modules distributed with the kernel

  As of version 1.2.2, many filesystems, a few SCSI drivers, several
  ethernet adapter drivers, and other odds and ends are loadable as
  modules. To use them, first make sure that you don't configure them
  into the regular kernel; that is, don't say y to it during `make
  config'.  Compile a new kernel and reboot with it. Then, cd to
  /usr/src/linux again, and do a `make modules'. This compiles all of
  the modules which you did not specify in the kernel configuration, and
  places links to them in /usr/src/linux/modules.  You can use them
  straight from that directory or execute `make modules_install', which
  installs them in /lib/modules/x.y.z, where x.y.z is the kernel
  release.


  This can be especially handy with filesystems. You may not use the
  minix or msdos filesystems frequently. For example, if I encountered
  an msdos (shudder) floppy, I would insmod
  /usr/src/linux/modules/msdos.o, and then rmmod msdos when finished.
  This procedure saves about 50k of RAM in the kernel during normal
  operation. A small note is in order for the minix filesystem: you
  should always configure it directly into the kernel for use in
  ``rescue'' disks.



  9.  Other configuration options

  This section contains descriptions of selected kernel configuration
  options (in make config) which are not listed in the configuration
  section.  Most device drivers are not listed here.



  9.1.  General setup


  Normal floppy disk support - is exactly that. You may wish to read
  over the file drivers/block/README.fd; this is especially important
  for IBM Thinkpad users.


  XT harddisk support - if you want to use that 8 bit XT controller
  collecting dust in the corner.


  PCI bios support - if you have PCI, you may want to give this a shot;
  be careful, though, as some old PCI motherboards could crash with this
  option. More information about the PCI bus under linux is found in the
  PCI-HOWTO.


  Kernel support for ELF binaries - ELF is an effort to allow binaries
  to span architectures and operating systems; linux seems to be headed
  in that direction.


  Set version information on all symbols for modules - in the past,
  kernel modules were recompiled along with every new kernel. If you say
  y, it will be possible to use modules compiled under a different
  patchlevel. Read README.modules for more details.





  9.2.  Networking options

  Networking options are described in the NET-2-HOWTO.


  10.  Tips and tricks



  10.1.  Redirecting output of the make or patch commands


  If you would like logs of what those `make' or `patch' commands did,
  you can redirect output to a file. First, find out what shell you're
  running: `grep root /etc/passwd' and look for something like
  `/bin/csh'.


  If you use sh or bash,

  (command) 2>&1 | tee (output file)


  will place a copy of (command)'s output in the file `(output file)'.


  For csh or tcsh, use

  (command) |& tee (output file)




  For rc (Note: you probably do not use rc) it's

  (command) >[2=1] | tee (output file)





  10.2.  Conditional kernel install

  Other than using floppy disks, there are several methods of testing
  out a new kernel without touching the old one. Unlike many other Unix
  flavors, LILO has the ability to boot a kernel from anywhere on the
  disk (if you have a large (500 MB or above) disk, please read over the
  LILO documentation on how this may cause problems). So, if you add
  something similar to

  image = /usr/src/linux/arch/i386/zImage
      label = new_kernel


  to the end of your LILO configuration file, you can choose to run a
  newly compiled kernel without touching your old /vmlinuz (after run-
  ning lilo, of course). The easiest way to tell LILO to boot a new ker-
  nel is to press the shift key at bootup time (when it says LILO on the
  screen, and nothing else), which gives you a prompt.  At this point,
  you can enter `new_kernel' to boot the new kernel.

  If you wish to keep several different kernel source trees on your
  system at the same time (this can take up a lot of disk space; be
  careful), the most common way is to name them /usr/src/linux-x.y.z,
  where x.y.z is the kernel version. You can then ``select'' a source
  tree with a symbolic link; for example, `ln -sf linux-1.2.2
  /usr/src/linux' would make the 1.2.2 tree current. Before creating a
  symbolic link like this, make certain that the last argument to ln is
  not a real directory (old symbolic links are fine); the result will
  not be what you expect.



  10.3.  Kernel updates

  Russell Nelson ([e-mail]) summarizes the changes in new
  kernel releases. These are short, and you might like to look at them
  before an upgrade. They are available with anonymous ftp from
  ftp.emlist.com in pub/kchanges or through the URL

  http://www.nvg.unit.no/linux-changes/index.html





  11.  Misc



  11.1.  Author


  The author and maintainer of the Linux Kernel-HOWTO is Brian Ward
  ([e-mail]). Please send me any comments, additions,
  corrections, or computers. Corrections are, in particular, the most
  important to me. You can look at my `home page' at one of these URLs:

  http://www.math.psu.edu/ward/
  http://blah.tu-graz.ac.at/~ward/




  Even though I try to be attentive as possible with mail, please
  remember that I get a lot of mail per day, so it may take a little
  time to get back to you. Especially when emailing me with a question,
  please try extra hard to be clear and detailed in your message. I do
  not care if you ask simple questions; remember, if you don't ask, you
  may never get an answer! I'd like to thank everyone who has given me
  feedback.


  Version -0.1 was written on October 3, 1994; this document is
  available in SGML, PostScript, TeX, roff, and plain-text formats.



  11.2.  To do

  The ``Tips and tricks'' section is a little small. I hope to expand on
  it with suggestions from others.

  So is ``Additional packages.''

  More debugging/crash recovery info needed.






  11.3.  Contributions

  A small part of Linus' README (kernel hacking options) is inclusive.
  (Thanks, Linus!)

  [e-mail] (Ulrich Callmeier): patch -s and xargs.

  [e-mail] (Daniel Quinlan): corrections and additions in
  many sections.

  [e-mail] (Nat MAKAREVITCH): mrproper

  [e-mail] (Axel Boldt): collected descriptions of kernel
  configuration options on the net; then provided me with the list

  [e-mail] (Steve Lembark): multiple boot suggestion

  [e-mail] (Keith Briggs): some corrections and
  suggestions

  [e-mail] (Eric Dumas): did a French translation

  [e-mail] (Michael J Donahue): typos, winner of the
  ``sliced bread competition''

  The people who have sent me mail with questions and problems have also
  been quite helpful.



  11.4.  Copyright notice and copying

  Copyright (c) Brian Ward, 1994, 1995.

  This document may be distributed in any medium as long as it and this
  notice remain unaltered. Permission is granted for translation into
  any language, so long as the translator's name is added to the
  document.  There is no warranty on this document and its contents; no
  one may be held liable for any unfortunate outcome of its content.


  Commercial redistribution is allowed and encouraged; however, it is
  strongly recommended that the redistributor contact the author before
  the redistribution, in the interest of keeping things up-to-date. The
  same is true for translations.